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REMARKS/ARGUMENTS 

Claims 1-54 are in the case. 

The Applicants have studied the office action dated January 19, 2007 and believe the 
application is in condition for allowance. Reconsideration and reexamination are respectfully 
requested. 

The Examiner has rejected the claims as anticipated (§ 102(e)) by US Pat. No. 6,754,773 
to Ulrich. This rejection is respectfully traversed. 

Claim 1, for example, is directed to a "data management method, comprising: receiving 
multiple user files from at least one client station coupled to a data storage subsystem; storing at 
least some of the multiple user files in a retrieval storage pool at a first location in the data 
storage subsystem; creating a managed file comprising an aggregation of at least some of the 
multiple user files; applying first predetermined criteria to a user file stored in the retrieval 
storage pool to designate the user file in the retrieval storage pool as one of a higher priority and 
a lower priority; and deleting from said retrieval storage pool a user file designated as lower 
priority." It is the Examiner's position that the recited "creating a managed file comprising an 
aggregation of at least some of the user files" is met by the description in the Ulrich reference of 
the server creating a new file and allocating a new G-node for the new file, citing columns 41 
and 42, lines 63-67 and lines 1-42 of the Ulrich reference. The applicants respectfully disagree. 

The Ulrich reference makes clear that the new file created by the server is a single user 
file created at the request of a client: 

"The process 1800 begins in a start state 1805 and moves to a state 1810 where the client 1 10 

send a file allocation request that includes a filename for a new file and a file handle for the new 

file's parent directory. 

The process 1800 moves to the state 1815, and the server node 150 indicated in the parent 
directory's file handle receives the file allocation request." Ulrich, col. 41, lines 49-55 

Thus, the file creation cited by the Examiner in the Ulrich reference clearly cannot be said to be 
"creating a managed file comprising an aggregation of at least some of the user files" as 
required by claim 1 . 
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The Examiner interprets the server's allocation of a "G-node" for the new file as the 
"aggregation of at least some multiple user files". However, the Ulrich reference makes clear 
that the cited "G-node" is neither a user file nor an aggregation of user files: 

"A G-node Table 330 includes a collection of G-nodes, where each G-node contains data 

related to attributes of a file. A one-to-one correspondence exists between the G-nodes and files 

stored on the server node 150." Ulrich, col. 22, lines 9-12. 

Thus, it is clear that the cited G-node contains data related to attributes of a user file but is clearly not a 
user file itself. Moreover, a G-node appears to relate to attributes of a single user file and not an 
aggregate of user files. 

The Examiner has cited no portion of the Ulrich reference which in any manner teaches 
or suggests "creating a managed fde comprising an aggregation of at least some of the user files" 
as required by claim 1. Independent claims 14, 27, 40, 50, and 53 may be distinguished in a 
similar fashion. 

It is the Examiner's position that the recited "applying first predetermined criteria to a 
user file stored in the retrieval storage pool to designate the user file in the retrieval storage pool 
as one of a higher priority and a lower priority" of claim 1 is met by a description of a checksum 
comparison operation provided in col. 40, lines 19-44 of the Ulrich reference. However, it is 
respectfully submitted that the Examiner's citation appears to describe a process for looking up a 
"file handle" at the request of a client: 

"FIG. 16 is a flow chart that describes in more detail how the process of the state 1515 
carries out a file handle look-up. The look-up process 1515 begins with a look-up request that 
comprises the file handle 1300 for a directory on the pathname of the desired file and continues 
on through each component of the pathname, retrieving a file handle for each, until a file handle 
for the desired file itself is returned to the client 1 10." Ulrich, col. 39, lines 39-41. 

It is clear that the checksums are not ordered to assign priorities to individual files but are instead 
ordered to facilitate finding a particular file handle. Still further, it is clear that the checksums 
are not ordered for purposes of determining which user files are to be deleted from a storage pool 
but are instead ordered to facilitate finding a particular file handle. 
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It is the Examiner's position that the recited "applying first predetermined criteria to a user file 
stored in the retrieval storage pool to designate the user file in the retrieval storage pool as one of 
a higher priority and a lower priority" of claim 1 is met by a description of a file storage 
operation provided in column 62, lines 20-27 of the Ulrich reference. However, it is respectfully 
submitted that the Examiner's citation appears to describe a process for determining how a file is 
to be stored, not as to whether a file is to be deleted: 

"In one embodiment, the server 130 determines how to store data based on the 
composition of the file and the availability of the different types of parity groups. As shown in 
FIG. 32A, of the different choices for storing File #1, the first parity string 3240 is most efficient 
as it has the lowest total bytes required for storage (5 120 bytes total), as well as, a high utilization 
value (100%). Each of the other parity strings 3241-3243 are less desirable for storing the data in 
File #1 due to greater space requirements (larger number of total bytes) and in some cases 
reduced storage efficiency (lower utilization value)." Ulrich, col. 62, lines 17-27. 

It is clear that the parity groups are not considered for purposes of determining which user files 
are to be deleted from a storage pool but are instead evaluated to determine a more optimum 
storage format. 

The Examiner has cited no portion of the Ulrich reference which in any manner teaches 
or suggests "applying first predetermined criteria to a user file stored in the retrieval storage pool 
to designate the user file in the retrieval storage pool as one of a higher priority and a lower 
priority" as required by claim 1. Independent claims 14, 27, 40, 50, and 53 may be distinguished 
in a similar fashion. 

It is the Examiner's position that the recited "deleting from said retrieval storage pool a 
user file designated as lower priority" of claim 1 is met by the following recitation in the Ulrich 
reference: 

"Furthermore, the one or more Gees corresponding to the logical disk blocks where the 
data from the file is stored are updated to reflect their now occupied status (i.e. removed from 
pool of available or free disk space)." Ulrich, col. 63, lines 59-62. 
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The applicants strongly disagree. The recitation above has no teaching or suggestion of 
deleting a user file. It is respectfully submitted that it relates to the opposite, that is, a description 
of the removal of free space (not the removal of a user file) as a result of the storage (not 
removal) of data. The Examiner has cited no portion of the Ulrich reference which in any 
manner teaches or suggests "deleting from said retrieval storage pool a user file designated as 
lower priority" wherein the deleted user file was received "from at least one client station 
coupled to a data storage subsystem" as required by claim 1 . Independent claims 14, 27, 40, 50, 
and 53 may be distinguished in a similar fashion. 

The rejection of the dependent claims is improper for the reasons given above. 
Moreover, the dependent claims include additional limitations, which in combination with the 
base and intervening claims from which they depend provide still further grounds of patentability 
over the cited art. 

The Examiner has made various comments concerning the anticipation of additional 
features of the present inventions. Applicants respectfully disagree. Applicants have addressed 
those comments directly hereinabove or the Examiner's comments are deemed moot in view of 
the above response. 
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Conclusion 

For all the above reasons, Applicants submit that the pending claims 1-54 are patentable 
over the art of record. Applicants have not added any claims. Nonetheless, should any 
additional fees be required, please charge Deposit Account No. 09-0466. 

The attorney of record invites the Examiner to contact him at (310) 553-7977 if the 
Examiner believes such contact would advance the prosecution of the case. 

Dated: March 19, 2007 By: /William Konrad/ 
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